Skip to content

seed scripts not readable by effective user mysql when mounted volume #429

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 8 commits into from

Conversation

qrkourier
Copy link

also chown -R .../initdb.d to user mysql while root prior to gosu exec mysql

qrkourier added 7 commits May 17, 2018 22:31
…ipts are not necessarily readable depending on mountpoint perms and after this point in the script all execution is EID mysql
…s a failure mode preventing execution of entrypoint in some version I can't remember
… may not have permission to read a docker volume mounted on the usual initdb.d path
… to assign host address" when service is not available
@tianon
Copy link
Member

tianon commented Jul 25, 2018

Sorry for the delay!

This PR is changing a number of seemingly unrelated things -- can you please describe the problem you're having (and trying to solve here) in more detail?

@qrkourier
Copy link
Author

The failure mode is that seed scripts in /docker-entrypoint-initdb.d are not readable by effective user "mysql". This problem presents when that directory is a Docker volume mount point and the mounted files are not readable by "mysql" user. The proposed solution is to change the entrypoint script to first copy the same seed scripts into the running container, set filemodes to make readable by "mysql" user before dropping privileges with gosu.

Unrelated is the problem of sporadic failure during docker build because the HKP keyserver is not available. The proposed solution is a list of alternative keyservers. This could easily become a separate PR if it's muddying the water.

@yosifkit
Copy link
Member

yosifkit commented Aug 6, 2018

The failure mode is made clear by #453. As far as copying and chowning the files from docker-entrypoint-initdb.d I would say no since some users already create an image with their files built in (instead of bind-mounting) and that this would duplicate the required space which might be a full database dump of multiple gigabytes.

@yosifkit yosifkit closed this Aug 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants